It is typically know in the art that an Instruction Set Architecture (ISA) describes the instructions, operations; register files, encoding/decoding logic, and field assignments of a processor that are made visible to the programmer. An ISA that supports a Very Long Instruction Word (VLIW) specifies one or more instruction formats. Each format can contain one or more slots which in turn contain one or more operations.
The Tensilica Instruction Extension (TIE language) described in U.S. Pat. No. 6,477,683 entitled “Automated Processor Generation System For Designing A Configurable Processor And Method For The Same” and TIE language extensions described in U.S. Pat. No. 6,477,697 entitled “Adding Complex Instruction Extensions Defined In A Standardized Language To A Microprocessor Design To Produce A Configurable Definition Of A Target Instruction Set, An HDL Description Of Circuitry Necessary To Implement The Instruction Set, And Development And Verification Tools For The Instruction Set” and TIE language extensions described in U.S. Pat. No. 7,346,881 by A. Wang et al. entitled “Method And Apparatus For Adding Advanced Instructions In An Extensible Processor Architecture”, all of which are incorporated herein by reference, describe constructs that allow an ISA to be specified. The TIE constructs require that all sizes, field assignments, and encoding/decoding logic be explicitly described, and thus an ISA described using those constructs is referred to as an explicit ISA.
The Xtensa architecture contains a core set of explicitly defined ISA elements consisting of lengths, formats, slots, fields, operations, and other elements. The TIE constructs are used to extend the core Xtensa ISA with new explicitly defined lengths, formats, slots, operations, fields, etc. Extending a core ISA with explicit constructs includes the user manually performing a number of tasks that are difficult and time-consuming; such as selecting encoding/decoding logic for operations, and selecting field assignments for operations' operands. Also, changing one explicit ISA construct can require the user to rewrite many other constructs. For example, increasing the number of registers in a register file results in the size of all fields used to access the register file increase, which may require new field assignments for some or all of the fields, which may in turn require new encoding/decoding logic for some or all of the operations. To simplify the process of extending the core Xtensa ISA, there is a need in the art for a method of describing a partially-explicit ISA. A partially-explicit ISA allows some or all of the ISA elements to be described without explicitly specifying sizes, field assignments, and encoding/decoding logic.
The prior art length and format constructs require that the encoding/decoding logic be described explicitly, as shown in the following example:                length l64 64 {InstBuf[3]=1′b1}        format f64 l64 {InstBuf[3:0]=1′b1000}        
The prior art slot construct specifies a slot within a format, and requires that the bits of the format that compose each slot be given explicitly, as shown in the following example:                length l64 64 {InstBuf[3]=1′b1}        format f64 l64 {InstBuf[3:0]=1′b1000}        slot s0 f64[32:4]        slot s1 f64[63:33]        
The prior art “iclass”, “opcode”, “operand”, “field”, and reference constructs specify a new operation, as shown in the following example:                field op0 Inst[3:0]        field t Inst[7:4]        field s Inst[11:8]        field r Inst[15:12]        opcode ADD.N op0=4′b1010        operand arr r AR {AR[r]}        operand ars s AR {AR[s]}        operand art t AR {AR[t]}        iclass iclass_add {ADD.N} {out arr, in ars, in art} { }        reference ADD.N {assign arr=ars+art;}        
The field construct requires that the bits of the slot composing the field be given explicitly. The opcode construct sets out that the encoding/decoding logic included to recognize the operation be given explicitly.
However, this prior art system does not address the problem of extending an existing, explicit ISA with new partially-explicit ISA elements, as occurs, for example, when adding partially-explicit ISA elements to the core Xtensa ISA. Given the ability to specify new partially-explicit ISA elements, either through the use of new TIE constructs or some other mechanism, it becomes necessary to automatically create the undefined portions of the ISA without violating the constraints imposed by the explicit ISA elements.
Certain limitations in systems that describe automatic creation of a new instruction sets include the inability to extend existing explicit ISA with a partially-explicit ISA elements.
Thus, there is need in the art for a new partially-explicit TIE construct to specify length and format that does not require encoding/decoding logic. Additionally, there is a need for a partially-explicit TIE construct to specify a slot without requiring the explicit bits that compose the slot. Furthermore, there is need in the art for a new partially-explicit TIE construct to allow an operation to be specified without requiring the corresponding field and opcode constructs to be given explicitly. In particular, there is need in the art for a system that can create an explicit ISA from a partially-explicit ISA based on the following:                the encoding/decoding logic created for partially-explicit length constructs must not conflict with the encoding/decoding logic for any explicit length constructs;        the encoding/decoding logic created for partially-explicit format constructs must not conflict with the encoding/decoding logic for any explicit format constructs;        the format bits assigned to a partially-explicit slot construct must not conflict with the format bits assigned to explicit slots within the same format; and        the encoding/decoding logic created for a partially-explicit operation must not conflict with the encoding/decoding logic of any explicit operations within a slot.        